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Executive  Summary 

Numerous  astrodynamic  algorithms  have  been  independently  re-developed  by  Air  Force 
Space  Command  (AFSPC)  over  the  past  twenty-five  years  to  fulfill  its  Space  Control 
mission.  The  result  was  a  proliferation  of  redundant  algorithms  that  were  all  maintained 
separately  at  increased  cost  and  risk  to  AFSPC. 

In  1995,  Astrodynamic  Standard  algorithms  were  developed  in  FQRTRAN  77  by 
AFSPC  to  emulate  the  operational  algorithms  used  by  the  AF  Space  Control  Center 
(AFSCC)  at  Cheyenne  Mountain  Air  Force  Station  and  reduce  the  proliferation  of 
redundant  algorithms.  Hundreds  of  copies  of  the  AFSPC  Astrodynamic  Standards  have 
been  released  to  the  user  community  and  the  code  has  been  integrated  successfully. 

Today,  requests  for  standards  come  from  developers  who  want  a  callable  astrodynamic 
library  function  that  will  feed  a  graphics  application  and  a  database.  They  also  want 
modular  code  that  can  function  on  different  platforms  across  local  or  worldwide 
networks.  While  the  standards  had  successfully  contributed  to  reduce  software 
development  and  maintenance  costs,  their  current  form  was  inadequate  to  easily  meet 
modern  software  development  requirements. 

This  paper  describes  AFSPC’s  current  effort  to  upgrade  the  AFSPC  Astrodynamic 
Standards  to  meet  modern  developer  needs.  AFSPC  is  also  planning  to  establish 
astrodynamic  standard  software,  as  callable  library  functions,  within  the  AFSCC. 
AFSPC’s  goal  is  to  provide  a  “Gold  Standard’’  suite  of  astrodynamic  standard  software 
that  will  ensure  accuracy,  minimize  risk  and  cost,  and  provide  users  with  rapid 
implementation  of  new  improvements. 

Historic  Motivation  to  Develop  Standards 

Numerous  astrodynamic  tools  and  algorithms  have  been  developed  by  Air  Force  Space 
Command  (AFSPC)  to  fulfill  its  Space  Surveillance  mission.  These  algorithms  were 
tested,  reliable,  and  compatible  with  the  data  gathered  and  distributed  for  use  by  the 
Space  Surveillance  Network  (SSN).  However,  as  network  users  updated  old  systems 
and  brought  new  ones  on  line,  site-specific  software  was  often  developed.  Many  times 
it  fell  on  the  site  contractor  to  create  or  obtain  software  that  would  process  and  produce 
SSN  data.  Since  it  was  often  difficult  to  obtain  the  desired  software  from  AFSPC, 
contractors  would  develop  a  solution.  The  result  was  a  proliferation  of  redundant 
algorithms  that  were  all  maintained  separately  at  increased  cost  and  risk  to  AFSPC. 
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A  viable  solution  was  to  release  existing  software  to  qualified  users.  The  problem  was 
that  SSN-compatible  software  included  extremely  large  and  complex  bodies  of  code 
written  under  a  computing  paradigm  that  assumed  full  time  dedicated  software 
maintainers,  minimum  use  of  memory,  and  full  optimization  of  execution  time.  It  was 
born  of  an  era  when  thousands  of  punch  cards  were  meticulously  prepared  and  stored 
in  large  boxes,  and  hardware  maintenance  costs  often  exceeded  those  of  software 
maintenance.  Developers  prior  to  1980  could  not  foresee  the  advent  of  analysis  tools, 
high  speed  computing  on  cheap  and  reliable  PCs,  distributed  applications,  the  internet, 
powerful  graphics  applications,  advanced  developer  environments,  modular  code  and 
object-oriented  languages  that  emphasize  reuse  of  code,  flexibility,  platform 
independence,  and  reduced  software  maintenance  budgets.  Today,  a  desktop  PC 
handles  in  seconds  or  minutes  a  job  that  took  a  mainframe  hours  to  run.  Job  runs  that 
humbled  the  mighty  Cray  supercomputers  of  a  decade  ago  are  routine  on  the  latest 
desktops. 

AFSPC  Role  in  Astrodynamic  Standards 

In  1991  USSPACECOM/J3  tasked  HQ  AFSPC/DO  to  be  the  technical  lead  for 
astrodynamic  standards.  Despite  the  monolithic  and  inflexible  nature  of  the  code  used 
on  the  main  frame  computers,  the  physics  of  the  astrodynamic  models  were,  and  still 
are,  comparable  to  anything  available  today,  so  during  the  early  90's  AFSPC  undertook 
the  task  of  extracting  desired  algorithms  from  the  larger  programs  in  SPADOC  and 
officially  recognized  them  as  the  AFSPC  Astrodynamic  Standards.  They  were  created  to 
provide  tested,  trusted,  and  centrally  maintained  SSN  compatible  code  to  ensure 
interoperability,  and  to  avoid  spending  money  reinventing  and  separately  maintaining 
code  whose  capability  was  already  available.  These  algorithms  are  currently  released 
as  no  cost  GOTS  (  Government  off  the  shelf )  products  to  qualified  DOD  contractors 
and  Government  users  for  installation  in  programs  that  use  or  provide  data  to  the  SSN. 

AFSPCI60-102,  ’’Space  Surveillance  Astrodynamic  Standards”,  sets  the  minimum 
standards  required  for  interoperability  within  the  space  surveillance  mission  area. 
Although  this  instruction  was  established  in  1996,  HQ  AFSPC/DOY  later  determined 
that  it  was  not  being  enforced.  As  a  result,  HQ  AFSPC/DOY  is  currently  updating  this 
instruction  and  is  seeking  Command  approval  for  specifying  the  use  of  AFSPC 
astrodynamic  standards  in  all  new  or  upgraded  AFSPC  systems  that  use  satellite 
trajectories  and  related  data  from  the  Air  Force  Space  Control  Center  (AFSCC). 

AFSPC  Reasons  for  Requiring  Use  of  Astrodynamic  Standards 

There  are  basically  three  reasons  for  the  Command's  advocacy  of  astrodynamic 
standards:  (1)  ensuring  the  accuracy  of  astrodynamic  algorithms  used  throughout  the 
Command,  (2)  minimizing  the  risk  and  cost  of  providing  required  algorithms  for  AFSPC 
operational  units,  and  (3)  maintaining  the  ability  to  rapidly  distribute  improved 
astrodynamic  algorithms. 


1)  Accuracy: 

The  accuracy  of  an  astrodynamic  algorithm  is  primarily  a  function  of  its  underlying 
physics  model  and  the  accuracy  and  compatibility  of  the  data  it  uses.  It  is  easy  to 
understand  that  the  "better"  the  underlying  physics  model  or  the  more  accurate  the 
data,  the  more  accurate  the  algorithm's  calculation.  However,  it  is  not  as  intuitively 
obvious  that  the  prediction  model  must  also  be  compatible  with  those  models 
generating  the  orbital  data  that  it  uses  as  input. 

If  the  data  products  (satellite  orbit  element  sets  or  vectors)  produced  by  the  AFSCC 
orbit  fit  algorithm  are  used  by  a  customer  with  a  compatible  algorithm,  they  will  make 
the  "most  accurate"  calculation  possible.  However  if  this  AFSCC  satellite  orbit  vector  is 
used  by  a  customer  with  a  non-compatible  algorithm,  they  will  get  a  "less  accurate" 
answer. 

Figure  1.  gives  an  example  of  an  actual  operational  incompatibility  when  predicting  the 
location  of  a  satellite.  A  user  wanted  to  upgrade  their  WGS-72  geopotential  model  to 
the  more  accurate  WGS-84.  However,  they  were  still  receiving  their  data  input  in  the 


Figure  1.  Predictions  with  AFSCC  vectors  using  WGS-72  versus  WGS-84 


form  of  WGS-72  produced  vectors  from  the  AFSCC.  They  had  an  accuracy 
requirement  for  DMSP  satellites  that  a  prediction  v\/ould  still  be  within  one  kilometer  after 
three  days,  which  they  met  with  their  old  WGS-72  model  (as  shown  in  dark  blue  in  the 
table  above).  However,  if  they  had  decided  to  upgrade  to  the  incompatible,  “but  more 
accurate,"  geopotential  model  they  would  have  failed  to  meet  this  requirement  even 
after  one  day,  let  alone  three  (as  shown  in  light  blue  in  the  table  above). 

To  ensure  compatibility  the  customer’s  astrodynamic  algorithm  needs  to  be  the  same 
algorithm  that  was  used  in  the  AFSCC  to  generate  the  input  orbital  data. 

2)  Minimize  Risk  and  Cost 

There  are  hundreds  of  customers  within  AFSPC,  using  AFSCC  data  products  to  make 
similar  astrodynamic  calculations.  Building  new  algorithms  for  every  operational  unit  is 
needlessly  expensive  and  only  adds  risk  to  mission  success  because  the  resulting 
algorithm  may  be  incorrect.  The  Verification,  Validation  and  Accreditation  (W&A) 
needed  to  ensure  correctness  is  also  expensive  and  time  consuming.  However,  the 
cost  doesn’t  end  with  an  algorithm's  initial  development.  AFSPC  must  continue  to  pay 
for  sustainment  of  all  these  systems.  Individually  maintaining  multiple  stovepipes  adds 
unnecessary  risk  and  cost. 

3)  Rapid  Updates 

AFSPC  would  like  to  be  able  to  make  improvements  to  astrodynamic  algorithms  and 
distribute  them  rapidly  throughout  AFSPC.  This  requires  that  both  the  algorithms 
(models)  and  the  computer  software  are  standardized. ..astrodynamic  standard 
software,  if  you  will. 

In  the  past  AFSPC  has  been  constrained  in  making  improvements  to  the  AFSCC 
algorithms  because  their  customers  could  not  easily  make  the  same  changes  to  their 
operational  code.  If  the  AFSCC  develops  an  improved  astrodynamic  algorithm  but  the 
other  AFSPC  operational  units  don’t  adopt  it,  that  SCC  “improvement”  would  only  cause 
incompatibilities  between  the  SCC  data  products  and  the  customer’s  astrodynamic 
algorithms.  Therefore,  in  many  cases  new  improvements  to  the  SCC  algorithms  could 
not  be  effectively  implemented  because  of  the  subsequent  cost  to  the  operational  units 
using  their  products  (e.g.  there  are  users  today  that  are  still  using  the  1960’s  orbit 
propagator  called  SGP). 

The  technology  exists  today  to  build  “Gold  Standard”  astrodynamic  algorithms 
...astrodynamic  standard  software... that  would  reside  in  the  AFSCC.  Improvements 
could  be  made  to  the  AFSCC  software  and  that  same  software  could  then  be 
simultaneously  released  to  all  customers  within  AFSPC.  If  the  customer  has  built  their 
application  to  interface  with  this  modular  software,  then  it  would  just  be  a  simple  plug- 
and-play  update  for  them.  This  would  be  similar  to  how  we  now  get  our  new  version 
releases  of  Microsoft  Word  for  example,  the  customer  does  not  have  to  build  new  code 
or  compile  new  code  in  order  to  implement  the  improved  version.  However,  until  all  of 


the  legacy  users  are  updated  to  the  modular  code,  AFSPC  will  continue  to  supply  the 
products  needed  to  meet  their  mission  requirements. 

Difficulties  with  Current  Standards  Implementation 

Hundreds  of  copies  of  the  Astrodynamic  Standards  have  been  released  to  the  user 
community  and  the  code  has  been  integrated  successfully.  However,  the  increasing  cry 
has  been  for  modular  pieces  of  code  that  are  called  like  a  simple  function  and  return  an 
answer.  Developers  want  the  code  written  in  the  language  of  their  choice  or  as  a 
callable  function  to  support  integration  in  larger  applications  that  further  process  the 
data.  The  current  releasable  standards  are  written  in  FORTRAN  77  and  have  an 
inflexible  DOS-type  user  interface,  which  takes  input  and  writes  an  output  file  which  is 
not  changeable  by  the  user.  As  a  result,  developers  are  motivated  to  request  the 
source  code,  and  thereby  incur  the  risk  of  corrupting  the  tested  standard  code  and 
forcing  additional  software  maintenance.  The  associated  costs  are  passed  on  to 
AFSPC,  and  costly  hybrid  algorithms  proliferate.  The  problem  that  precipitated  creating 
standards  was  not  completely  solved.  While  the  standards  have  successfully 
contributed  to  reduce  software  development  and  maintenance  costs,  their  current  form 
is  inadequate  to  easily  meet  modern  software  development  requirements. 

Migrating  Astrodynamic  Software  into  the  New  Century 

Requests  for  standards  today  come  from  developers  who  want  a  callable  astrodynamic 
library  function  that  will  feed  a  graphics  application  and  a  database.  They  create  their 
own  user  interfaces  and  format  their  own  output  to  feed  graphical  displays  and  various 
databases.  They  want  modular  code  that  can  function  on  different  platforms  across 
local  or  worldwide  networks. 

AFSPC  has  started  a  phased  effort  to  modernize  the  astrodynamic  standards  (see 
Appendix  A  for  a  description  of  these  standards)  to  meet  modern  developer  needs.  The 
following  steps  are  involved: 

1)  Untangle  and  modularize  the  F77  code  while  migrating  to  FORTRAN  95,  which 
represents  minimal  risk  within  funding  constraints.  FORTRAN  95  is: 

a)  Accessible  to  users,  directly  or  through  a  C  wrapper.  This  includes  legacy  ADA, 
C,  and  F77  users  as  well  as  developers  using  object-oriented  languages. 

b)  Supported  by  modern  software  analysis  tools  and  developer  environments  that 
simplify  program  maintenance  and  reduce  associated  costs. 

c)  Lends  itself  to  eventual  migration  to  C/C++  or  JAVA. 

2)  Remove  unnecessary  interfaces  and  allow  for  developers  to  use  their  own  designs 
for  input  and  output  (I/O).  While  a  simple  driver  program  would  accompany  each 
algorithm  and  would  provide  simple  input  and  output,  developers  are  free  to  replace 
it  with  their  own. 

3)  Provide  the  algorithm  as  a  callable  library,  shared  object,  or  Dynamic  Linked  Library 
(DLL).  Once  the  user  adds  the  compiled  library  to  their  code  and  links  it  to  his/her 
program,  the  algorithm  is  accessed  by  a  single  function  call. 

4)  Migrate  the  code  if  necessary  to  C,  which  is  most  flexible  for  inter-language  calling. 


5)  Move  toward  platform  independent  executable  libraries  as  resources  permit. 

Status  of  the  FORTRAN  95  Software  as  of  1  March,  2001 

1)  The  Simplified  General  Perturbations  4  (SGP4)  propagator  algorithm  has  been 
delivered  and  has  undergone  extensive  code  review  and  testing.  It  has  been 
compiled  into  a  static  library  on  the  (SGI)  UNIX  platform  and  a  DLL  on  the  Intel  PC. 
Release  of  Version  5.0  will  take  place  in  March. 

2)  The  Special  Perturbations  (SPEPH)  propagator  algorithm  has  been  delivered  and 
has  undergone  extensive  code  review  and  testing.  Numerical  tests  so  far  are 
successful  and  additional  driver  software  is  being  written  to  develop  the  DLL  and  the 
customer  sample  application. 

3)  The  Computation  of  Miss  Between  Orbits  (COMBO)  algorithm  has  been  delivered 
and  has  undergone  extensive  code  review  and  testing.  Numerical  tests  so  far  are 
successful  and  additional  driver  software  is  being  written  to  develop  the  DLL  and  the 
customer  sample  application. 

4)  The  Look  Angles  Module  (LAMOD)  algorithm,  used  for  calculating  sensor  site  look 
angles  to  acquire  passing  satellites,  has  been  delivered  and  has  undergone 
extensive  code  review  and  testing.  Numerical  tests  so  far  are  successful  and 
additional  driver  software  is  being  written  to  develop  the  DLL  and  the  customer 
sample  application. 

5)  The  Report/Observation  Association  (ROTAS)  algorithm  has  been  delivered  and  has 
undergone  extensive  code  review  and  testing.  Numerical  tests  so  far  are  successful 
and  additional  driver  software  is  being  written  to  develop  the  DLL  and  the  customer 
sample  application. 

6)  Additional  algorithms,  including  SGP4/SP  DC,  lOMOD,  AOF,  FOV,  and  SEQDC, 
are  currently  being  developed. 

Concerns 

However  some  concerns  have  been  expressed  concerning  astrodynamic  standards. 
One  concern  is  that  an  instruction  or  regulation  doesn't  mean  much  if  it  can't  be 
enforced.  This  is  the  reason  AFSPC/DOY  is  seeking  Command  approval  for  specifying 
the  use  of  AFSPC  astrodynamic  standards.  One  way  to  create  an  enforceable  set  of 
standards  is  to  incorporate  them  into  the  Operational  Requirements  Document  (ORD) 
for  new  or  upgraded  systems.  This  is  a  method  that  AFSPC/DOY  advocates  and  is 
trying  to  determine  the  most  appropriate  method  of  incorporation. 

Another  concern  is  that  if  restrictive  performance  and  interoperability  standards  get  set 
by  the  command,  the  customer  will  be  unable  to  exploit  numerous  commercial  space 
operations  software  applications  that  may  be  perfectly  suitable  for  the  intended  mission. 
There  are  two  facets  to  this  concern,  customers  with  “unique”  requirements  and  those 
whose  needs  are  met  by  the  current  algorithms  but  who  would  also  like  to  be  able  to 
“exploit”  the  graphical  capabilities  of  COTS  products. 


For  the  case  when  the  standards  do  not  meet  users’  requirements,  the  proposed 
AFSPC  Instruction  does  not  prohibit  customers  from  developing  "specialized" 
algorithms.  AFSPCI60-102  allows  the  DO  and  DR  Command  Leads  to  submit  a 
request  for  a  waiver  from  using  the  astrodynamic  standards.  This  request  is  then 
reviewed  by  AFSPC/DO  to  determine  if  this  is  the  best  and  most  cost  effective  solution 
for  AFSPC.  If  a  waiver  is  granted,  the  AFSPC  operational  user  incurs  responsibility  for 
ensuring  the  "specialized"  algorithm  is  properly  W&Aed  and  is  compatible  with  the 
AFSCC  products  that  it  must  use. 

For  the  case  when  the  standards  do  meet  users’  requirements,  AFSPCI  60-102  will 
direct  their  usage;  thus  ensuring  accuracy,  minimizing  risk  and  cost  and  providing  for 
rapid  improvements.  Additionally,  the  future  AFSPC  CCTS  plug-in  module” 
astrodynamic  standards  will  satisfy  the  customers  within  AFSPC  who  would  like  to 
exploit  the  many  CCTS  visualization  products  available  and  yet  be  assured  they  get 
accurate  answers  with  AFSCC  data  products.  This  not  only  ensures  that  the  customer 
obtains  the  most  accurate  answers  that  they  require,  but  also  this  minimizes  risk  and 
cost  and  provides  the  ability  to  rapidly  incorporate  improved  astrodynamic  algorithms. 

The  Way  Ahead 

As  specified  by  the  Integrated  Space  Command  and  Control  (ISC2)  contract,  Lockheed 
Martin  and  their  ISC2  teammates  will  take  responsibility  for  maintaining  the  AFSPC 
Astrodynamic  Standards  Software.  Lockheed  Martin  will  assume  responsibility  from  the 
Space  Warfare  Center/Analysis  and  Engineering  Division  (SWC/AE)  for  maintenance 
and  distribution  of  all  the  current  and  to  be  developed  standards,  as  they  become 
available.  Also  specified  by  the  NCRAD/USPACECCM  Warfighting  Support  System 
(N/UWSS)  Technical  Architecture,  Lockheed  Martin  is  required  to  implement  the 
AFSPC  Astrodynamic  Standard  Software  in  new  products  for  ISC2. 

To  facilitate  this  transition,  AFSPC/DCY  and  SWC/AE  are  working  with  Lockheed  Martin 
to  provide,  assist  with  implementation  of,  and  perform  verification  and  validation  (V&V) 
of  the  new  software  as  it  is  being  developed.  This  is  a  big  step  towards  achieving 
AFSPC’s  goal  to  provide  a  “Gold  Standard”  suite  of  astrodynamic  standard  software 
that  will  ensure  the  most  accurate  answer  for  users  of  AFSCC  data,  minimize  risk  and 
cost,  and  provide  users  with  rapid  implementation  of  new  improvements. 


APPENDIX  A  -  AFSPC  Astrodynamic  Standard  Software 

SWC/AES  maintains,  for  AFSPC,  the  following  standardized  Astrodynamic  Software. 
The  AFSPC  Astrodynamic  Standards  are  currently  available  as  stand-alone  FORTRAN 
77  executable  modules  portable  to  UNIX,  PC,  or  VMS  platforms.  An  effort  is  currently 
underway  to  modularize  these  standards  in  FORTRAN  95  and  C. 

ORBITAL  APPLICATIONS 

•  Look  Angle  Generation  (LAMOD) 

•  Computation  of  Miss  Between  Orbits  (COMBO) 

•  Overfly  (AOF) 

•  Field  of  View  (FOV  -  Laser  Clearinghouse) 

•  New  Foreign  Launch  (NFL  -  initial  launch  parameters) 

•  Decay  Prediction  (SALTLIFE) 

EPHEMERIS  GENERATION 

•  SGP4 

•  SALT 

•  SP 

ORBITAL  CORRECTION 

•  SGP4DC 

•  SALTDC 

•  SPDC 

•  Sequential  DC 

OBSERVATION  ASSOCIATION 

•  ROTAS 

INITIAL  ORBIT  GENERATION 

•  lOMOD 

ELEMENT  CONVERSION 

•  Converts  element  sets,  vectors  or  observations  to  element  sets  or  vectors  of  another 

theory  type  (SGP4,  SALT  or  SP) 


AFSPC  ASTRODYNAMIC  STANDARDS 


1)  SGP4  -  (Simplified  General  Perturbations  #4)  -  Is  an  analytic  method  of  generating 
ephemerides  for  satellites  in  earth-centered  orbits. 

2)  SGP4DC  -  (SGP4  Differential  Correction)  -  Performs  a  least  squares  differential 
correction  of  orbital  elements  using  tracking  data  and  the  SGP4  propagator. 

3)  SP  -  (Special  Perturbations)  -  Is  an  algorithm,  which  uses  numerical  integration  to 
generate  ephemerides  for  satellites  in  earth-centered  orbits. 

4)  SPDC  -  (SP  Differential  Correction)  -  Performs  a  least  squares  differential  correction 
of  orbital  elements  using  tracking  data  and  the  SP  propagator. 

5)  SALT  -  (Semi-Analytic  Liu  Theory)  -  Is  a  semi-analytic  method  of  providing 
ephemerides  and  orbital  lifetime  analysis  for  satellites  in  earth-centered  orbits. 

6)  SALTDC  -  (SALT  Differential  Correction)  -  Performs  a  least  squares  differential 
correction  of  orbital  elements  using  tracking  data  and  the  SALT  propagator. 

7)  LAMOD  -  Computes  sensor  (ground  based  or  space  based)  viewing  opportunities 
(so-called  “look  angles”)  for  earth  centered  satellites.  LAMOD  uses  any  one  of  three 
ephemeris  generation  theories:  SGP4,  SALT,  and  SP. 

8)  lOMOD  -  Computes  an  initial  set  of  orbital  elements  from  three  observations. 

9)  AOF  -  (Area  Overflight)  -  AOF  computes  when  overhead  satellites  can  see  a 
particular  location  on  the  earth  (may  be  either  a  point,  circle,  or  box).  AOF  uses  any 
one  of  three  ephemeris  generation  theories:  SGP4,  SALT,  and  SP. 

10)  FOV  -  (Field-of-View)  -  FOV  determines  times  in  which  orbiting  satellites  fly  through 
a  ground  based  observer’s  conical  field  of  view.  The  field  of  view  can  be  defined  by  a 
constant  azimuth  and  elevation,  a  constant  right  ascension  and  declination,  or  as  a  line- 
of-site  to  another  orbiting  satellite.  FOV  uses  any  one  of  three  ephemeris  generation 
theories:  SGP4,  SALT,  and  SP. 

11)  COMBO  -  (Computation  of  Miss  Between  Orbits)  -  Computes  close  approaches 
between  satellites  using  any  one  of  three  ephemeris  generation  theories:  SGP4,  SALT, 
and  SP. 

12)  ROTAS  -  (Report/Observation  Association)  -  Associates  observations  against 
satellite  element  sets. 

13)  SEQDC  -  Sequential  Differential  Correction  performs  a  series  of  least-squares 
differential  corrections  (DC).  These  differential  corrections  are  computed  in  a  sequential 
mode,  which  uses  one  or  more  observations  or  tracks  while  retrieving  former  covariance 


information  from  a  prior  DC.  The  user  may  select  any  of  the  Astrodynamics  Standard 
ephemeris  generation  theories  SGP4,  SALT,  or  SP. 

14)  GELCON  -  Converts  element  sets  or  vectors  of  one  of  three  theories  (SGP4,  SALT, 
or  SP)  to  element  sets  or  vectors  of  a  selected  theory  (SGP4,  SALT,  or  SP). 


